home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / faq / comp / database / foxpro / rushmore < prev   
Text File  |  1994-04-08  |  14KB  |  365 lines
  1. Newsgroups: comp.databases.xbase.fox,comp.answers,news.answers
  2. Path: bloom-beacon.mit.edu!hookup!swrinde!cs.utexas.edu!uunet!mnemosyne.cs.du.edu!nyx10!kcochran
  3. From: kcochran@nyx10.cs.du.edu (Keith "Justified And Ancient" Cochran)
  4. Subject: FoxPro Databases FAQ #2: See Fox.  See Fox Run.  Run, Fox, Run.
  5. Message-ID: <1994Apr8.204541.22644@mnemosyne.cs.du.edu>
  6. Followup-To: comp.databases.xbase.fox
  7. Summary: Information about Rushmore technology in the Fox* databases.
  8. X-Disclaimer: Nyx is a public access Unix system run by the University
  9.      of Denver for the Denver community.  The University has neither
  10.      control over nor responsibility for the opinions of users.
  11. Keywords: fox, foxpro, foxbase, databases, 'woof'
  12. Sender: usenet@mnemosyne.cs.du.edu (netnews admin account)
  13. Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
  14. Date: Fri, 8 Apr 94 20:45:41 GMT
  15. Approved: news-answers-request@MIT.Edu
  16. Lines: 346
  17. Xref: bloom-beacon.mit.edu comp.databases.xbase.fox:3825 comp.answers:4827 news.answers:17837
  18.  
  19. Archive-name: databases/foxpro/rushmore
  20. Posting-frequency: Monthly
  21.  
  22. [This is version 1.0.0.1, last updated 03/06/94. New or altered text
  23. is marked with ">" in the left hand column.  Please send all comments,
  24. suggestions, and whatnot to kcochran@nyx.cs.du.edu]
  25.  
  26. One of the most my mysterious things about FoxPro is the Rushmore
  27. Technology.  This FAQ deals with Rushmore, and how to use it to get
  28. every last ounce of power out of your databases.
  29.  
  30. This FAQ is organized in the following manner:
  31.  
  32. 0.0 What is Rushmore?
  33. 0.1 What isn't Rushmore?
  34. 0.2 Why is it called Rushmore?
  35.  
  36. 1.0 How do I turn on Rushmore?
  37. 1.1 Where can I utilize Rushmore?
  38. 1.2 Where can't I utilize Rushmore?
  39. 1.3 How do I turn off Rushmore?
  40.  
  41. 2.0 Simple indexes and Rushmore.
  42. 2.1 Compound indexes and Rushmore.
  43. 2.2 Complex indexes and Rushmore.
  44.  
  45. 3.0 Using functions in indexes.
  46. 3.1 Using user-defined functions in indexes.
  47. 3.2 Using functions from .plb files in indexes.
  48.  
  49. 4.0 What is an "optimizable expression"?
  50. 4.1 Fully optimizable expressions.
  51. 4.2 Partially optimizable expressions.
  52. 4.3 Non-optimizable expressions.
  53.  
  54. 5.0 Rushmore and the SEEK statement.
  55. 5.1 Rushmore and the LOCATE statement.
  56. 5.2 Rushmore and the SET ORDER TO statement.
  57. 5.3 Rushmore and the SET RELATION TO statement.
  58. 5.4 Rushmore and the SET DELETED statement.
  59.  
  60. [Note each of these sections is seperate with "******"]
  61.  
  62. ******
  63. 0.0 What is Rushmore?
  64.     The "simple" answer:  Rushmore is this little bit of magic that allows
  65.     you main-frame database access speeds on a lowly PC.
  66.  
  67.     The "more complex" answer:  Rushmore is a data-access method that utilizes
  68.     binary selection critera and better index-manipulation methods to allow
  69.     faster resolution of searches.
  70.  
  71.     [If you want to know what the "more complex" answer is really saying,
  72.     take a graduate course in database programming.]
  73.  
  74.     The "correct" answer:  Rushmore is a mountain in South Dakota which has
  75.     been carved into the faces of several presidents. :]
  76.  
  77. ******
  78. 0.1 What isn't Rushmore?
  79.     Rushmore has nothing to do with satanism.
  80.     Rushmore has nothing to do with the power tools.
  81.     Rushmore has nothing to do with your report layouts.
  82.     Rushmore has nothing to do with your mouse or keyboard.
  83.  
  84. ******
  85. 0.2 Why is it called Rushmore?
  86.     Oddly enough, the design team came up with the "code-name" Rushmore
  87.     after spending a night watching the movie "North By Northwest."
  88.  
  89. ******
  90. 1.0 How do I turn on Rushmore?
  91.     You don't.  Any time you can include a FOR clause in a statement,
  92.     Rushmore will try to optimize the expression.
  93.  
  94.     Some exceptions apply.  For example, Rushmore will not activate if
  95.     you have a statement with a WHILE clause in it.
  96.  
  97.     Rushmore works best with .CDX indexes, but it will utilize any open
  98.     .IDX or compact .IDX indexes that it can get its greedy little hands
  99.     upon.
  100.  
  101. ******
  102. 1.1 Where can I utilize Rushmore?
  103.     You can utilize Rushmore in any FoxPro statement that allows a FOR
  104.     clause, or in an SQL statement.  If you are dealing with databases
  105.     of any size, you should utilize Rushmore as often as possible.
  106.  
  107.     Note:  The only way to utilize Rushmore when doing multi-database
  108.     access is through the SQL SELECT statement.
  109.  
  110. ******
  111. 1.2 Where can't I utilize Rushmore?
  112.     Basically, if you can't include a FOR clause, you can't use Rushmore.
  113.  
  114.     Rushmore also can't be used if you have a WHILE clause in your statement,
  115.     or if you are doing a LOCATE on the child table in a multi-table
  116.     relation.
  117.  
  118.     Note that SEEK and GOTO do not utilize Rushmore.
  119.  
  120. ******
  121. 1.3 How do I turn off Rushmore?
  122.     In some rare instances, you may want to turn off Rushmore so that it
  123.     doesn't try to optimize your expression.
  124.  
  125.     In order to do so there are two methods:
  126.  
  127.     SET OPTIMIZE ON|OFF - This turns Rushmore on/off until the next SET
  128.     OPTIMIZE statement is executed.  It is probably not a good idea to
  129.     use this statement.
  130.  
  131.     There is another way to disable Rushmore.  Any statement that can
  132.     utilize Rushmore has a NOOPTIMIZE clause.  This clause will disable
  133.     Rushmore for that statement.  Note that if you have a multi-line
  134.     statement, such as:
  135.  
  136.     SELECT db1
  137.     LOCATE FOR foo=bar NOOPTIMIZE
  138.     WHILE FOUND()
  139.        SELECT db2
  140.        LOCATE FOR date1 = m.mydate
  141.        WHILE FOUND()
  142.           [...]
  143.           CONTINUE
  144.        ENDWHILE
  145.        SELECT db1
  146.        CONTINUE
  147.     ENDWHILE
  148.  
  149.     Rushmore will be disabled for the db1 LOCATE, but will be active for
  150.     the db2 LOCATE.
  151.  
  152.     NB:  Be very wary of using GOTO, LOCATE, SEEK, SKIP or any other command
  153.     that may move the record pointer (like APPEND, or SQL - SELECT) in any
  154.     databases that are linked using SET RELATION TO.  You may not like the
  155.     results.
  156.  
  157. ******
  158. For the following discussions, we have the following database structure:
  159.    fname C(15)
  160.    minit C(1)
  161.    lname C(18)
  162.    dob D
  163.    ssn N(9,0)
  164.  
  165. ******
  166. 2.0 Simple indexes and Rushmore.
  167.     A simple index is of the form:
  168.  
  169.     INDEX ON ssn TAG ssn
  170.  
  171.     This is the type of index that Rushmore likes using the "best".  In
  172.     order to utilize Rushmore with this type of tag, all you have to do
  173.     is:
  174.  
  175.     LOCATE FOR ssn = 987654321
  176.  
  177.     Simple indexes are generally only built on numeric, date, or
  178.     formatted character fields.  For more information on why this is
  179.     so, see sections 2.2, 3.0, and 4.0.
  180.  
  181. ******
  182. 2.1 Compound indexes and Rushmore.
  183.     A coumpound index is of the format:
  184.  
  185.     INDEX ON lname+fname TAG name
  186.  
  187.     In order to utilize this type of tag with Rushmore, you have to:
  188.  
  189.     LOCATE FOR lname+fname = "Cochran Keith"
  190.  
  191.     What's that?  You want to know why you wouldn't use:
  192.  
  193.     LOCATE FOR name = "Cochran Keith"
  194.  
  195.     Well, there's a reason for that, and it's even a good one.  The TAG
  196.     parameter is for your usage. Rushmore understands expressions, not
  197.     tags.
  198.  
  199.     In order to get Rushmore to work, the expression on the left side of
  200.     the expression must match in essence the expression of the INDEX ON
  201.     statement.  So, the following are things that Rushmore can't utilize
  202.     with our current INDEX statement:
  203.  
  204.     LOCATE FOR UPPER(lname+fname) = "COCHRAN KEITH"
  205.     LOCATE FOR LTRIM(lname)+fname = "COCHRAN KEITH"
  206.     LOCATE FOR lname+" "+fname = "Cochran Keith"
  207.  
  208.     For a discussion of how to correctly utilize Rushmore with functions,
  209.     see sections 2.2 and 3.0.
  210.  
  211.     NB: Special care must be taken when creating compound or complex indexes
  212.     with numeric and date fields.  For more information, see the INDEX ON
  213.     section in the FAQ "Things your Mamma never told you".
  214.  
  215. ******
  216. 2.2 Complex indexes and Rushmore.
  217.     A complex index is any index that uses math, string, or other functions
  218.     as part of the index.  Some examples:
  219.  
  220.     INDEX ON DTOS(date) TAG cdate
  221.     INDEX ON lname+", "+fname TAG fullname
  222.     INDEX ON STR(ssn) TAG cssn
  223.     INDEX ON ssn+DAY(date) TAG mytag
  224.  
  225.     In order to get Rushmore to work with these indexes, the index expression
  226.     must match the expression you are locating on.
  227.  
  228. ******
  229. 3.0 Using functions in indexes.
  230.     As you've seen from the preceeding section, you can utilize any FoxPro
  231.     function in your index.  The question as far as Rushmore is concerned
  232.     is - should you?
  233.  
  234.     In most cases, the answer is yes.  The caveat here is that when you're
  235.     designing your database, you need to be aware of the trade-off between
  236.     getting better speed through Rushmore, and taking longer to update your
  237.     indexes when you change or add records.
  238.  
  239.     The other major pitfall with using functions in your indexes is how you
  240.     solve for the solutions later.  Most people, if they have an index on
  241.     UPPER(lname+fname), and two input fields, m.last and m.first, will
  242.     attempt to:
  243.  
  244.     LOCATE FOR UPPER(lname+fname) = UPPER(m.last+m.first)
  245.  
  246.     This will work, and Rushmore will optimize it, but you won't see any
  247.     real speed increase.  The reason for this is because the
  248.     UPPER(m.last+m.first) is evaluated for EVERY RECORD in the database.
  249.  
  250.     In order to properly utilize this index, you should:
  251.  
  252.     m.search = UPPER(m.last+m.first)
  253.     LOCATE FOR UPPER(lname+fname) = m.search
  254.  
  255. ******
  256. 3.1 Using user-defined functions in indexes.
  257.     Rushmore is able to utilize FoxPro functions in index expressions,
  258.     and it is also able to utilize user-defined functions (udf's) in
  259.     its optimization process.  There are several things you have to be
  260.     aware of, though:
  261.  
  262.     1) The speed that Rushmore can process is limited by how fast your
  263.        function executes.
  264.  
  265.     2) Be extremly careful about what your function does.  Your function
  266.        should make no guesses about the current operating environment, the
  267.        value of SET EXACT, SET ORDER, SET RELATION, etc.
  268.  
  269.     3) Your function ***MUST NOT*** modify any databases.  Doing so can
  270.        cause everything from "something strange is happening" to "FoxPro
  271.        must be buggy - it gets stuck in an endless loop."
  272.  
  273.     4) Be extremly careful about any variables you function may modify.
  274.        It's extremly easy to get the "wrong" result when your function
  275.        modifies one of your search variables.
  276.  
  277.     5) Your function ***MUST NOT*** move the record pointer in any database
  278.        hooked into the database you're using with SET RELATION.  It ***MUST
  279.        NOT*** move the record pointer in the current database.
  280.  
  281. ******       
  282. 3.2 Using functions from .plb files in indexes.
  283.     As long as the function in the .plb is "well behaved", there should be
  284.     no problems using it.  Remember the points in section 3.1, though.
  285.  
  286. ******
  287. 4.0 What is an "optimizable expression"?
  288.     An optimizable expression is any expression that Rushmore can attempt
  289.     to use.  How well Rushmore can work with the expression determines if
  290.     the expression is fully, partially, or non-optimizable.
  291.  
  292.     All of the examples used up to now were either fully optimizable, or
  293.     non optimizable.  Expressions that may be partially optimizable generally
  294.     take the format of:
  295.  
  296.     LOCATE FOR lname = "Cochran" AND ssn = 987654321
  297.  
  298. ******
  299. 4.1 Fully optimizable expressions.
  300.     In order for our last LOCATE statement to be fully optimizable, we
  301.     would have to:
  302.  
  303.     INDEX ON lname TAG lname
  304.     INDEX ON ssn TAG ssn
  305.  
  306.     This is the "best" solution, and will allow Rushmore to find the records
  307.     the fastest.
  308.  
  309. ******
  310. 4.2 Partially optimizable expressions.
  311.     If we had the index on ssn, but no index on lname, then our expression
  312.     would partially optimizable.  Rushmore would activate to locate the
  313.     records which matched our ssn, and then treat the rest of the expression
  314.     as a non-optimizable search.  Note that Rushmore is smart enough that
  315.     it will solve for the optimizable portions first, and then perform
  316.     the rest of the search on the subset of records it already has.
  317.  
  318. ******
  319. 4.3 Non-optimizable expressions.
  320.     A non-optimizable expression is one that Rushmore can't help.  You want
  321.     to avoid these expressions in all but the most extreme cases.  The
  322.     reason is that FoxPro will search every record in the database,
  323.     starting at RECNO() = 1.
  324.  
  325.  
  326. ******
  327. 5.0 Rushmore and the SEEK statement.
  328.     Basically, the SEEK statement, and the SEEK() function don't interact
  329.     with Rushmore at all.  This can be both a blessing and a curse.  For
  330.     simple indexes, you can get faster results out of SEEK than you
  331.     can out of Rushmore.  But SEEK will not allow you to search on
  332.     multiple fields...
  333.  
  334. 5.1 Rushmore and the LOCATE and SCAN statements.
  335.     Rushmore will almost always speed up your queries when using LOCATE FOR
  336.     or SCAN FOR statements.  To get the best use of Rushmore in these
  337.     statements, you should build simple indexes on the fields you will
  338.     most often search through.
  339.  
  340. 5.2 Rushmore and the SET ORDER TO statement.
  341.     Rushmore will optimize searches when you have SET ORDER TO in a database,
  342.     but there are some interesting results:
  343.  
  344.     (1)The speed of the search will be slower.  This is true whether you
  345.        are using Rushmore or not.
  346.     (2)The first record Rushmore locates (i.e. LOCATE FOR foo = "bar")
  347.        will be the lowest numbered record in the database [RECNO()] that
  348.        matches the search criteria, regardless of the SET ORDER TO clause.
  349.  
  350. 5.3 Rushmore and the SET RELATION TO statement.
  351.     Beware of attempting to use Rushmore along with SET RELATION.  Due
  352.     to the constraints of the SET RELATION statement, Rushmore will
  353.     either not work at all, or will only work in very limited cases.
  354.  
  355. 5.4 Rushmore and the SET DELETED statement.
  356.     Rushmore can optimize a query for deleted() IF you index on deleted().
  357.     If your database contains a large number of deleted records, you
  358.     can help Rushmore out by either indexing on deleted(), or by using
  359.     the SET DELETED OFF statement before you invoke Rushmore.
  360. --
  361. =kcochran@nyx.cs.du.edu | B(0-4) c- d- e++ f- g++ k(+) m r(-) s++(+) t | TSAKC=
  362. =My thoughts, my posts, my ideas, my responsibility, my beer, my pizza.  OK???=
  363. =I'm sure that Vicki Robinson would never let Kibo engage in genocide against =
  364. =Armenians in Turkey.                                                         =
  365.